接下來大略白話地介紹一下Scrum的架構與流程
接下來大略白話地介紹一下Scrum的架構與流程

首先, 每個專案會有一個(而且僅有一個)的Product Owner(PO)，他要負責做夢，幻想這個軟體系統能有什麼樣的功能，並將這些幻想依照他想像優先需要實現的順序，一條一條地列下來，稱之為Product Backlogs。

當然，我們還會有個實際上來開發系統的Team，團隊的大小通常是3到7個人左右，並且成員組成是跨功能屬性，裡頭會包含了完成這個專案所需要的人，像是美術、DBA、QA及RD等。並且他們的技能也有可能是跨領域的，像是美術能兼QA或是DBA能兼RD等。最後，這個團隊是自我組織以及自我管理的，也就是在沒人監視的情況下，也僅會適度地摸個小魚，但總是能按照進度完成任務。

在Product Owner幻想出Product Backlogs後，他就會跟Team來開個會，討論下一個Sprint要做些什麼，稱之為Sprint Planning Meeting。所謂的Sprint指的是2到4週的工作週期，Scrum將專案的開發時程切為一個一個固定的開發週期，並在每個Sprint開始時召開Sprint Planning Meeting，來計劃這個Sprint要做什麼事情，最後產出Sprint Backlogs紀錄所要完成的項目。

接下來就開始展開為期2週或4週的衝刺，在Sprint執行的當中，Sprint Backlogs是被凍結，如果突然有任何不在Sprint Backlogs規劃的項目想要插隊，都要正氣凜然的斷然拒絕。

在Sprint執行的每一天，所有團隊成員都會在固定時間，固定地點舉行Daily Standup Meeting，在這個會議中，成員們會輪流宣佈三件事：昨天我做了什麼、今天我打算做什麼和遇到什麼困難阻礙我完成工作。在這會議上並不做任何問題的討論，有需要或有興趣的成員，將在會議結束後再自行互相延續討論。

最後，在Sprint結束之前將舉行兩個會議。第一個是Review Meeting，團隊將向Product Owner和其他只出張嘴不做事的利害關係人展示這個Sprint所完成的成果。接下來會再召開Retrospective Meeting，對這個Sprint流程做回顧及改善建議，每個人可以發表自己覺得這個Sprint做的好的部份，可以改善的部份以及改善的建議，以做為下一個Sprint實施的依據。

因此，在一個Sprint結束後，理論上將會有個可以發行的產品，以及更多的幻想或修正版幻想進入到Product Backlogs，還有對於Sprint執行流程的回饋。

結束，就這麼簡單 XD